Number input by viridia · Pull Request #23842 · bevyengine/bevy

viridia · 2026-04-17T03:57:29Z

Objective

Part of #19236

Solution

A numeric text input widget. This includes:

Colored stripes ("sigils") for designating X, Y and Z input fields.
Character filtering
ValueChange events

Not supported:

Validation error events
Range and precision options

Additional changes in this PR:

Added small labels (related to text inputs only insofar as numeric inputs have small labels above them in the editor design).
Refactored labels to be simple spans instead of nested entities - this required a non-inherited text font theme component, so we renamed the existing component to have the word "inherited" in the name.
Consolidated the way focus outlines work for text inputs and other widgets
I had to make changes to Slider and other widgets to support the is_final flag in ValueChange. This is necessary to allow listeners the choice between spammy and not-spammy updates when listening to widget outputs.

Testing

Manual testing

Showcase

github-actions · 2026-04-17T06:20:34Z

It looks like your PR has been selected for a highlight in the next release blog post, but you didn't provide a release note.

Please review the instructions for writing release notes, then expand or revise the content in the release notes directory to showcase your changes.

changes to some of the other widgets.

Atlas16A · 2026-04-18T18:02:39Z

range and percision should prob be added but im fine with that coming in a later PR

jordanhalase

My thoughts on this

kfc35

Reviewed everything. The example seems to work fine for me. Just have a few comments/questions

kfc35 · 2026-04-20T01:48:37Z

    {
        drag_end.propagate(false);
+        if state.0 && !disabled {
+            let local_pos = transform.try_inverse().unwrap().transform_point2(


nit: I was looking if some of this logic has been extracted into a function (calculating a normalized local position), and there is a function on ComputedNode that does parts of this logic: normalize_point

Just for your consideration. I’ve noticed similar logic used in color_plane

kfc35 · 2026-04-20T02:28:22Z

+/// Component which causes the color of a text span to be set based on a theme color. Unlike
+/// [`InheritableThemeTextColor`], this can work when set directly on the text span entity, and is
+/// not inherited.
+// TODO: This is necessary because an entity with Propagate doesn't update itself, only its


What is the action item in this TODO?

The real action item here is not to use Propagate, but something else. However, that's a much larger discussion.

kfc35 · 2026-04-20T04:45:51Z

+}
+
+/// Observer function which updates the [`NumberInputValue`] in response to a [`ValueChange`] event.
+pub fn number_input_self_update(value_change: On<ValueChange<f32>>, mut commands: Commands) {


I’m not sure if this is a plausible scenario that merits fixing, but If focus is not on the EditableText, this particular observer is hooked in, and NumberInputValue is inserted by some other system, does this make a loop?

NumberInputValue is inserted

number_input_on_value_change is triggered On<Insert, NumberInputValue>

Because EditableText does not have focus, it queues editable_text edits

apply_text_edits emits a TextEditChange

number_input_on_text_change is triggered On<TextEditChange>

number_input_on_text_change emits a ValueChange

number_input_self_update is triggered On<ValueChange<f32>

A NumberInputValue is inserted

I assume because it requires that focus not be on the EditableText that this scenario probably won’t happen, but figured I’d bring it up if it’s actually important or to clear up if I’m misunderstanding something

We could avoid this by changing the self update function to only update the value if the value has changed. This would break the cycle.

Updating the number input is now done by triggering an event rather than inserting a component.

ickshonpe · 2026-04-20T18:19:16Z

        drag_end.propagate(false);
-        commands.entity(slider_ent).remove::<Pressed>();
-        if drag.dragging {
+        if drag.dragging && !disabled {


What happens if InteractionDisabled is added middrag, won't it get stuck with Pressed and drag.dragging = true.

Same with the others, shouldn't we remove Pressed from a control on release, even if it has InteractionDisabled

That's a good idea.

ickshonpe · 2026-04-20T18:43:10Z

+/// Used to indicate what format of numbers we are editing. This primarily affects the type
+/// of [`ValueChange`] event that is emitted.
+#[derive(Component, Default, Clone, Copy)]
+pub enum NumberFormat {


I was thinking of a value input design with an InputValuePlugin<T> for each supported value type T, rather than an enum discriminator. So users could have an input for any type that can be parsed from a string. Then it could support a Val input for instance where values like "10px" or "25%" are both valid, for example.

I'm not against merging this, and leaving discussions about generalization until later though.

I prefer that design too :)

kfc35

I think this is in a good enough state to merge and to have some follow ups later for anything still pending (except for my comment about drag end and InteractionDisabled).

kfc35 · 2026-04-20T20:08:53Z

+                                        :group_body
+                                        Children [
+                                            :label("A standard group"),
+                                            :label_small("Scalar property"),


When running the example, there’s a bit of unexpected behavior here now:

Focus on the first scalar property

Update the value to something different

Tab navigate to the second scalar property (copy)
Note that, here, the second scalar property is not updated with the value from the first scalar property field

Tab navigate again away from the second scalar property (or just click anything but the first scalar property to unfocus the second scalar property)
Observe that the first scalar property is set back to the value that is in the second scalar copy property

I expected the first scalar property’s change to be reflected in the second scalar property after I tab switched focus from the first to the second scalar copy.

I suspect the cause is due to number_input_on_update not applying UpdateNumberInput to focused entities.

However, I don’t feel this is too pressing to fix in this PR if it’s not trivial to fix / would affect other actually desirable UX. This can be a follow up if this is something that should be fixed. This is a bit of a contrived example and I don’t know how much this will actually be surfaced in practice.

What you are seeing is a race condition between the two focus events: because the second input acquires focus before the focus-lost event is received for the first input, this blocks the second one from being updated.

alice-i-cecile

I'm happy enough with this design now; I'd prefer to merge and iterate :)

viridia added 4 commits April 16, 2026 20:50

Number input

63ebcf4

cargo format.

3931ee0

CI

c61c25f

CI

2e26a4e

alice-i-cecile requested review from ickshonpe and kfc35 April 17, 2026 06:20

alice-i-cecile added C-Feature A new feature, making something new possible A-UI Graphical user interfaces, styles, layouts, and widgets M-Release-Note Work that should be called out in the blog due to impact S-Needs-Review Needs reviewer attention (from anyone!) to move forward labels Apr 17, 2026

github-project-automation Bot added this to UI Apr 17, 2026

github-project-automation Bot moved this to Needs SME Triage in UI Apr 17, 2026

alice-i-cecile added X-Uncontroversial This work is generally agreed upon D-Modest A "normal" level of difficulty; suitable for simple features or challenging fixes labels Apr 17, 2026

viridia added 2 commits April 17, 2026 17:56

Added final field to ValueChange. This required substantial

246ee62

changes to some of the other widgets.

update release notes.

ff19f25

Merge remote-tracking branch 'upstream/main' into number_input

650884c

alice-i-cecile added this to the 0.19 milestone Apr 19, 2026

jordanhalase suggested changes Apr 19, 2026

View reviewed changes

Comment thread crates/bevy_feathers/src/controls/number_input.rs Outdated

kfc35 reviewed Apr 20, 2026

View reviewed changes

viridia added 4 commits April 20, 2026 10:04

Added NumberFormat option, changed representation to f64.

cafcb32

number_input now emits different value types based on number format.

07245a0

Updating the number input is now done by triggering an event rather than inserting a component.

Typo

9ab60c6

More typos

66863a5

ickshonpe reviewed Apr 20, 2026

View reviewed changes

viridia added 2 commits April 20, 2026 11:30

Allow drag end even if slider disabled (avoids getting stuck).

1e50601

Fixed a few bugs from previous commit.

e115bbb

ickshonpe reviewed Apr 20, 2026

View reviewed changes

alice-i-cecile added D-Complex Quite challenging from either a design or technical perspective. Ask for help! and removed D-Modest A "normal" level of difficulty; suitable for simple features or challenging fixes labels Apr 20, 2026

kfc35 approved these changes Apr 20, 2026

View reviewed changes

Review feedback

6020140

alice-i-cecile approved these changes Apr 21, 2026

View reviewed changes

alice-i-cecile added S-Ready-For-Final-Review This PR has been approved by the community. It's ready for a maintainer to consider merging it and removed S-Needs-Review Needs reviewer attention (from anyone!) to move forward labels Apr 21, 2026

Merge remote-tracking branch 'upstream/main' into number_input

0253a23

alice-i-cecile enabled auto-merge April 21, 2026 05:22

alice-i-cecile added this pull request to the merge queue Apr 21, 2026

Merged via the queue into bevyengine:main with commit 64fe756 Apr 21, 2026
42 checks passed

github-project-automation Bot moved this from Needs SME Triage to Done in UI Apr 21, 2026

Uh oh!

Conversation

viridia commented Apr 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Objective

Solution

Testing

Showcase

Uh oh!

github-actions Bot commented Apr 17, 2026

Uh oh!

Atlas16A commented Apr 18, 2026

Uh oh!

jordanhalase left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

kfc35 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ickshonpe Apr 20, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

kfc35 left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

kfc35 Apr 20, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

alice-i-cecile left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

7 participants

viridia commented Apr 17, 2026 •

edited

Loading

ickshonpe Apr 20, 2026 •

edited

Loading

kfc35 Apr 20, 2026 •

edited

Loading